Database management systems are often required to support numerous requests in parallel, as various processes and threads make requests to read and write to data maintained by the system. Concurrent access, however, is accompanied by an associated risk of conflicting updates and inconsistent reads. For example, a client application might attempt to view and edit a record. The process begins with the record being read from the database and ends with updated data being written to the database. However, if two client applications attempt to work with the same data simultaneously, there may be a risk that the two clients will conflict with each other—for example by attempting to write different values to the same column. Another possible conflict involves inconsistent reads. This might occur, for example, if one of the client applications is updating multiple records in the context of a single transaction. If the first client application's updates are underway when the second client attempts to read the same data, there is a risk that the second client will be provided with some of the first client's updates, but not all of them.
Various locking schemes or other concurrency control schemes may be employed to reduce or eliminate these risks. Database systems may provide various locking mechanisms that isolate client applications from each other's activity. The protection afforded by the database management system can be expressed as an isolation level. Some isolation levels impose locks on all data implicated within a transaction, while others provide minimal locking or even no locking at all. Higher levels of isolation can correspond to a decrease in system performance, because locks slow down other applications trying to read the same data.
For some applications, such as large-scale web applications, the cost of increased isolation can be prohibitive. One approach to avoiding these problems involves what is called optimistic concurrency, which avoids transaction-related locking under the belief that in most cases no conflicts will occur. Client applications written to use optimistic concurrency may include error detection and correction algorithms, so that they may properly react to conflicts when they occur. This approach, however, can be both complex and error-prone.
A further possible complication relates to the volume of updates. Even at lower levels of isolation, large volumes of updates to a table, row or individual field can cause serious performance degradation. As one example, an inventory value may track the in-stock quantity of a popular product. Numerous customers may attempt to check the availability of the product and then attempt to purchase it. If a high degree of isolation is imposed, for example by serializing each customer's access, the system could grind to a halt. If no isolation is imposed, there would be a significant risk of purchases exceeding the available inventory.